System having generalized client-server computing

ABSTRACT

A protocol provides generalized client-server computing by providing a server program that can utilize standard and non-standard ports for applications.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.11/249,075, filed Oct. 12, 2005 now U.S. Pat. No. 7,320,027, which is adivisional of U.S. patent application Ser. No. 10/140,537 filed May 7,2002 now abandoned which claims the benefit of U.S. Provisional PatentApplication No. 60/290,774, filed May 14, 2001, each of which areincorporated herein by reference in their entirety.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH

Not Applicable.

FIELD OF THE INVENTION

The present invention relates generally to communication networks and,more particularly, to networks having client-server communication.

BACKGROUND OF THE INVENTION

As is well known in the art, personal portable networking devices (suchas wireless personal digital assistants and network appliances) arebecoming increasingly popular. As the number of such devices increases,the number of new applications running on these portable devices is alsoincreasing. These portable devices require, in addition to traditionalclient-type applications such as Web browsing, server-type applications,e.g., server programs running on the user's device.

However, using the conventional networked-computing model, which iscommonly referred as the “client-server” model, it is relativelydifficult for a service provider to support large scale server-typecomputing to subscribers for a variety of reasons. For example, theprivate Internet Protocol (IP) addresses assigned to server deviceslocated behind a firewall are invisible to clients located outside thefirewall. In addition, even if the service provider can assign publicInternet Protocol version 4 (IPv4) addresses to server devices behindthe firewall, the service provider may not have enough such addresses tomaintain a sufficient number of connections across the firewallsimultaneously. Further, the conventional “client-server” model isserver-centric and is effective at supporting a few well-knownapplications, each identified by a well-known port number.

For personal server-type applications, which may be of high diversityand not well known, it is inconvenient to associate each of theseapplications with a fixed port number. Also, although secure versions ofvarious protocols have been developed for the purpose of protectingcommunications privacy, an eavesdropper can still determine the type ofcommunications that are flowing between a client and a server byobserving the well-known server port number.

It would, therefore, be desirable to provide a protocol that overcomesthe aforesaid and other disadvantages.

SUMMARY OF THE INVENTION

The present invention provides a protocol for providing generalizedclient-server computing. With this arrangement, a client can submit aservice request to a server that includes a module for installing aprogram from the client and selecting a port for the program. The servermodule then commands the installed program to listen for client servicerequests on the selected port. While the invention is primarily shownand described in conjunction with wireless devices and Internetprotocols, it is understood that the invention is applicable to networksin general in which generalized client-server computing is desirable.

In one aspect of the invention, a client sends a service request messageto a server via a gateway. A module on the server receives the requeston a standard port, selects a server port and launches the requestedprogram, which is commanded by the server module to listen on theselected port. The server module then sends a response to the client viathe gateway that includes the selected port information for therequested program.

In an exemplary embodiment, the client sends an IP address query messageto a default domain name service (DNS) server, using the server'shostname. The query eventually arrives at the border DNS server in theserver's network. The border DNS server replies with the public IPaddress of a generalized server application (GSA) gateway that serves asthe gateway router for the server's subnet and has the lightest load.The client ultimately receives the IP address of the GSA gateway. Usinga uniform resource locator (URL) to indicate the requested serverapplication, a client then sends a service request message to the GSAgateway at the standard TCP port for the generalized client-serverprotocol, as if the GSA gateway were the server. The GSA gateway sendsan IP address query message to the border DNS, using the internalnetwork interface. The border DNS server replies with the private IPaddress of the server. The GSA gateway forwards the service requestmessage to the server and, more particularly, to the daemon programlistening to the standard TCP port for the generalized client-serverprotocol.

The daemon program selects a port on the server, launches the requestedserver program and commands the server program to listen to the selectedport. The daemon program then sends a response message back to the GSAgateway, with a “server-port” parameter. The GSA gateway creates a newnetwork address/port translation (NAPT) record in its look-up table. Inthe record, an unused port number at the external interface is used toreplace the port number given by the server as the public port number.The GSA gateway then rewrites the “server-port” parameter and sends theresponse message back to the client. The GSA gateway also periodicallybroadcasts this NAPT record to other GSA gateways. The client initiatesclient-server communications with the server using the GSA gateway'spublic IP address and the returned server port that also belongs to theGSA gateway. The subsequent client-server traffic is routed by GSAgateways according to the NAPT record.

With this arrangement, firewalls are transparent to client-servercomputing in both directions (from outside clients to inside servers andfrom inside clients to outside servers), even though the connectionsremain under the control of firewalls. In addition, a service providerneeds a relatively low number, e.g., a few hundreds to thousands, ofpublic IPv4 addresses to support millions of connections acrossfirewalls simultaneously. Further, server-type applications areidentified by URLs (instead of a fixed port number), which can beencrypted for better communications privacy. The advantages of thegeneralized client-server computing system include users, such aswireless device users, receiving information without polling servers onthe network periodically. Thus uplink traffic in the service provider'snetwork can be reduced significantly. Further new server-typeapplications can be easily developed to push information to users, suchas location-based applications. In addition; privacy for clients andservers is enhanced by hiding the type of communication being exchanged.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be more fully understood from the following detaileddescription taken in conjunction with the accompanying drawings, inwhich:

FIG. 1 is a schematic representation of a system having generalizedclient-server computing in accordance with the present invention;

FIG. 2 is a schematic depiction of a server that can form a part of thesystem of FIG. 1;

FIG. 3 is a flow diagram for implementing generalized client-servercomputing in accordance with the present invention;

FIG. 4 is a further schematic depiction of a system having generalizedclient-server computing in accordance with the present invention; and

FIG. 5 is a data flow diagram showing generalized client-servercomputing in accordance with the present invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 shows an exemplary system 100 providing a generalizedclient-server protocol for personal server-type computing in accordancewith the present invention. In general, a client 102 interacts with aserver 104 via a network 106 to launch existing applications and installnew applications on the server. To enhance the flexibility of thesystem, the server 104 can be identified by a character string, such asa URL, and a port number can be designated for new applications asdescribed more fully below.

In an exemplary embodiment shown in FIG. 2, a server 200, which cancorrespond to the server 104 of FIG. 1, is provided as a portableIP-based networking device supporting generalized server computing inaccordance with the present invention. The server 200 runs a servermodule or daemon program 202 after power up. The server 200 includesfirst and second I/O connectors 204 a,b each having a series of portsfor interconnecting various network devices in an manner well known toone of ordinary skill in the art. During normal operation, the daemonprogram 202 listens to a predetermined port, e.g., a TCP port, that isthe well-known port for a particular generalized client-server protocoland waits for incoming connection requests.

The daemon program 202 can also listen to a non-standard TCP port,depending on configurations by the user. It is understood, however, thatif the daemon program 202 listens to a non-standard TCP port, the daemonmay not be able to receive connection requests from clients outside offirewalls.

Referring again to FIG. 1 in combination with FIG. 2, when the client102, which can be provided as a portable IP-based networking device,requests service for a generalized server application, the client firstsends a service request message to the daemon program 202 running at theserver using the standard or non-standard TCP port for the particulargeneralized client-server protocol.

In an exemplary embodiment, the service request message from the client102 has the following format, which is similar to that of an HTTPrequest message.

-   -   Command+“ ”+Generalized server application URL+“ ”+Version        number+CR+LF    -   CR+LF    -   Parameter name+“:”+Parameter value+CR+LF    -   Parameter name+“:”+Parameter value+CR+LF    -   Parameter name+“:”+Parameter value+CR+LF    -   CR+LF    -   Optional content

An illustrative command set includes “GET” and “PUT” commands. A “GET”command instructs the daemon program 202 to launch the requested serverprogram 206, which already exists on the server, for conventionalclient-server computing. A “PUT” command instructs the daemon program202 to install a new server program 208, which is wrapped in theoptional content, on the server 200 and optionally to launch it forconventional client-server computing.

In general, “PUT” commands include the optional content and a“content-length” parameter that identifies the number of bytes for theoptional content. Note that the optional content can include a recursivestructure. That is, the optional content can contain a child parameterblock and, optionally, a child optional content. In this case, a“child-parameter-block” parameter must be presented in the parentparameter block and, if a child optional content exists, another“content-length” parameter that identifies the number of bytes for thechild optional content should be included in the child parameter block.

In one embodiment, the generalized server application URL has thefollowing format.

-   -   Protocol name+“://”+Server hostname+Optional port        number+“/”+Optional server program filename

In one particular embodiment, the protocol name is “gsa” (generalizedserver application) or “sgsa” (secure generalized server application).The server hostname is a dotted character string, e.g., a URL, such aspcluo.research.att.com, which identifies the server host. It should benoted that it is preferred not to use an explicit IP address for thepurpose of keeping transparency for generalized server-type computingacross firewalls. The optional port number begins with a character,e.g., “:”. In general, the port number is included only if the daemonprogram is not listening to the standard well-known port for thegeneralized client-server protocol. The optional server program filenameidentifies the generalized server program with a path that may or maynot be a full path, depending on the configuration for the user.

If the protocol name is “sgsa”, the optional server program filenamedoes not exist in the URL. Instead, a “server-program-filename”parameter can be used for this purpose. In this case, all parametersexcept some cryptographic configuration parameters, such as“encryption-algorithm” and “MAC-algorithm,” can be encrypted as a childparameter block and wrapped in the optional content. The encryption keyshould be a pre-arranged key between the client and the server or shouldbe the public key of the server. The exchange of encrypted informationis well known to one of ordinary skill in the art.

After receiving the service request message, the daemon program 202decrypts the parameters in the child parameter block if necessary,interprets the command, and proceeds as described below.

In response to a “GET” command, the daemon program 202 first determineswhether the requested server program has already been running on theserver. If so, the daemon program 202 sends a positive response messageback to the client 102. Otherwise, the daemon program 202 selects a portand launches the server program 206, which listens to the selected port.

In case of a “PUT” command, the daemon program 202 first checks theuser's security policy on running server programs sent to the client104, determines whether the server environment satisfies the runningrequirements, and verifies the digital signature and client's securitycertificate, if necessary. After verification, the daemon program 202installs the server program 208, selects a port, launches the serverprogram, and commands the program 208 to listen to the selected port.

In one embodiment, the service request message from the client 102includes a “linger-time” parameter indicating how long the serverprogram 208 can continue running after the last active connection isclosed. A server program that supports the generalized client-servercomputing should accept two command line parameters, namely“server-port” and “linger-time.”

Regardless of whether the requested server program can be launchedsuccessfully, the daemon program 202 sends a response message back tothe client, which can have the following format (similar to that of anHTTP response message):

-   -   Protocol name and version number+“ ”+Response code+“ ”+Response        message+CR+LF    -   CR+LF    -   Parameter name+“:”+Parameter value+CR+LF    -   Parameter name+“:”+Parameter value+CR+LF    -   Parameter name+“:”+Parameter value+CR+LF    -   CR+LF    -   Optional content

The response code identifies whether the server program is ready. If so,a “server-port” parameter is included in the response message.Otherwise, the reason of failure is indicated by the response code.Similarly, if there exists an optional content, a “content-length”parameter is included to identify the number of bytes for the optionalcontent.

If the protocol name is “sgsa”, the parameters, except somecryptographic configuration parameters and the “server-port” parameter,can be encrypted as a child parameter block and wrapped in the optionalcontent. The encryption key should be a pre-arranged key between theclient and the server or the public key of the client. In an exemplaryembodiment, the “server-port” parameter is not encrypted to retaintransparency for generalized server-type computing across firewalls.

After receiving a positive response message and decrypting parameters inthe child parameter block, if necessary, the client 102 can initiate theconventional client-server communications to the server 200 using thereturned server port.

FIG. 3 shows an exemplary sequence of steps for implementing generalizedclient-server computing in accordance with the present invention. Thedescribed steps assume a successful service request and no firewall.

In step 300, a client sends a service request message to a daemonprogram at the server, which listens to the standard or non-standard TCPport for the generalized client-server protocol. In an exemplaryembodiment, a URL is used to indicate the requested server application.In step 302, the daemon program selects a port on the server, in step304 launches the requested server program and, in step 306, commands theserver program to listen to the selected port. The daemon program thensends a response message back to the client with a “server-port”parameter in step 308. In step 310, the client initiates client-servercommunications to the server using the returned server port.

The inventive generalized client-server protocol renders firewalls andnetwork address translators transparent to the generalized client-serverconnections on both directions (from inside clients to outside servers,and from outside clients to inside servers) while these connections arestill under control. It is understood that for the remainingdescription, transparency is discussed only for the connections fromoutside clients to inside servers, since existing firewalls and networkaddress translators are already transparent to the connectionsestablished on the other direction.

FIG. 4 shows an exemplary network 300 providing generalizedclient-server computing in accordance with the present invention. Thesystem 300 includes a border DNS server 302 and a series of GSA(generalized server application) gateways 304 a,b,c, on the borderbetween a private IP network 306, such as a service provider's privateIP network, and the Internet 308. Each of the border DNS server 302 andthe GSA gateways 304 a,b,c include respective internal networkinterfaces 310 a-d and external network interfaces 312 a-d. The system300 further includes a border gateway 314 coupled between the Internet308 and the GSA gateways 304. A client 316 is connected to the Internet308 and can request services from a server 318 coupled to the private IPnetwork 306.

In an exemplary embodiment, the private IP network 306 is at most aclass A subnet using an IPv4 subnet mask “10.x.x.x,” which is dedicatedto private IP networks. Alternatively, the private network can be anIPv6 network. It is understood, without limiting the invention, thatIPv4 implementations are shown and described herein to facilitate anunderstanding of the invention. In addition, it is assumed that GSAgateways 304 are on the same link at both internal and externalinterfaces for the purpose of simplicity. However, a variety ofalternative border configurations will be readily apparent to one ofordinary skill in the art. For example, if the private IP network 306has many subnets, the GSA gateways 304 can be grouped. The externalinterfaces 312 of the GSA gateways 304 are still on the same link, butonly the internal interfaces 310 of GSA gateways in the same group areon the same link.

It is understood that a GSA gateway 304, as used herein, refers to aparticular gateway router. The GSA gateway 304, in addition togeneralized client-server functionality in accordance with the presentinvention, can also function as a generalized client-server proxy, afirewall, and a network address/port translator. To be a generalizedclient-server proxy, a GSA gateway includes a daemon program listeningto the standard TCP port for the generalized client-server protocol, asdescribed above. As a firewall, a GSA gateway should include somepolicy-enforced routing functions, which can also apply to thegeneralized client-server computing traffic through the help of thegeneralized client-server proxy. To provide a network address/porttranslator function, the GSA gateway includes a look-up table in memory,each item of which, called a NAPT (network address/port translation)record, associates a pair of private IP address/port numbers, a pair ofpublic IP address/port numbers, and a timer together for an inside hostthat has an active connection to outside. In the present embodiment, thepublic IP address of a GSA gateway serves as the public IP address foran inside host.

The border DNS server 302 is used to answer IP address queries from bothinternal hosts (from the internal link 310) and external hosts (from theexternal link 312). If an IP address query comes from an internal hostand if the queried IP host is in the domain of the service provider'snetwork, a private IP address is returned, with a relatively long TTL(time-to-live). If an IP address query comes from an internal host, andif the queried IP host is on the Internet 308, a public IP address isretrieved from a corresponding DNS server, cached, and returned. If anIP address query comes from an external host and if the queried IP hostis in the domain of the service provider's network 306, the border DNSserver 302 checks the load statistics of GSA gateways that serve asgateway routers for the server's subnet and then returns the public IPaddress of the GSA gateway 304 that currently has the lightest load,with the shortest TTL. The border DNS server 304 should not answer anyquery from external hosts for any IP host that is not in the serviceprovider's network.

There are some additional protocols between the GSA gateways 304 a,b,con the same internal link. Each GSA gateway 304 periodically broadcastsits load information on the link so that every GSA gateway knows whichone has the lightest load. If one GSA gateway fails to broadcast for apredetermined amount of time, it is considered out of service by theother gateways. If this case, the GSA gateway that has the lightest loadamong living gateways can begin to run Proxy Address Resolution Protocol(ARP) for the dead GSA gateway and process all the traffic for the deadone, until the dead GSA gateway reclaims its existence.

There are also some additional protocols between the GSA gateways 304and the border DNS server 302 so that the border DNS server can tracethe load statistics and network configurations for the GSA gateways.

FIG. 5 shows an exemplary connection sequence diagram for an outsideclient OC to an inside server IS handled by a GSA gateway GSAa. Thediagram assumes that a client on the Internet wants to initiate aninventive generalized client-server connection to a server in a privateIP network. The client knows the server's hostname, for example,“pcluo.research.att.com,” but does not know the IP address of theserver.

The client OC first sends an IP address query message to its default DNSserver in step 400. The query message eventually arrives at the borderDNS server BD that is responsible for the domain of “.research.att.com.”The border DNS server BD then finds that this IP address query is froman external host and the queried IP host is an inside one. In step 402,the border DNS server BD selects a GSA gateway that has the lightestload and returns the public IP address of this GSA gateway to thequerying host. The returned IP address is assigned the shortest TTL sothat the DNS query result is prevented from being cached by the defaultDNS server at the client side.

In step 404, after receiving the IP address query result, the client OCsends a service request message to the GSA gateway GSA using thestandard well-known TCP port for the generalized client-server protocol,as if the GSA gateway GSAa were the server host“pcluo.research.att.com.”

After receiving the service request message from the client, the GSAgateway first checks all kinds of security policy, includingper-subscriber policy, to see if the service request can go through thefirewall. If not, the GSA can immediately send a negative responsemessage to the client in step 412 b. Otherwise, the GSA gateway needs toforward the service request message to the server. Assuming the GSAgateway does not know the server's private IP address, in step 406 theGSA gateway GSAa sends an IP address query message to the border DNSserver BD using the internal network interface. As a consequence, theborder DNS server finds that this IP address query is for an internalhost from another internal host, and thus returns the private IP addressof the server to the GSA gateway in step 408, with a relatively longTTL, which allows the GSA gateway to cache this DNS query result forperformance improvement.

After receiving the private IP address of the server, the GSA gatewayforwards the service request message to the server in step 409, usingthe private IP address and the standard well-known TCP port for thegeneralized client-server protocol. The GSA gateway can insert a“linger-time” parameter in the forwarding message, which is equal to theexpiration time associated for a NAPT record in the look-up table. Inthe above process, if the client uses “sgsa” instead of “gsa” toidentify the protocol, the GSA gateway cannot know what type ofcommunications will happen shortly between the outside client OC and theinside server IS. If this situation is contrary to the security policyset by the service provider, the GSA gateway GSAa denies the servicerequest immediately by sending a negative service response message tothe client in step 412 b.

After receiving the service request message from the GSA gateway, thedaemon program at the server IS interprets and processes the message asif the GSA gateway GSAa were the client, and sends a response messageback to the GSA gateway in step 410.

After receiving a positive response message from the server IS, the GSAgateway may need to create a NAPT record in the look-up table using anunused port number of the GSA gateway at the external interface as thepublic port number for the server. The port number can be selected froma so-called NAPT port range, e.g., 10000-30000, such that the GSAgateway can immediately identify whether an incoming IP packet istargeting itself or an inside host based on the destination TCP/UDP portnumber of the incoming IP packet. The public IP address of the GSAgateway serves as the public IP address for the server IS. The value ofthe “server-port” parameter given by the server IS is also saved in theNAPT record as the private port number for the server IS. It is thenreplaced by the public port number in the response message that isforwarded by the GSA gateway to the client in step 412 a.

As soon as the GSA gateway finishes forwarding the response message, thetimer associated with the new NAPT record starts ticking. In addition,the GSA gateway needs to broadcast this new NAPT record to all GSAgateways GSAb-N on the same link in order for other GSA gateways to beable to route the return traffic back to the client in step 414, asdiscussed below. The GSA gateway GSAa also needs to broadcast this NAPTrecord periodically within an interval less than the value of thelinger-time parameter. It is understood that for efficiency, all or someof NAPT records can be bundled together in broadcast.

After receiving a positive response message from the server IS, the GSAgateway forwards it to the client OC in step 412 a.

After receiving the response message from the GSA gateway, the client OCcan initiate a conventional client-server connection to the server,using the returned server port.

In subsequent client-server connection requests, IP packets sent fromthe client OC to the server IS arrive at the external network interfaceof the GSA gateway in step 416, because the destination IP address isthe GSA gateway's public IP address. Whenever receiving an IP packetfrom the external network interface, the GSA gateway first determineswhether the destination port number of the IP packet belongs to the NAPTport range. If so, the GSA gateway then determines whether it appears asa public port number for an inside host in some NAPT record in thelook-up table. If it is, the destination IP address and port number ofthis IP packet, which are public, are replaced by the correspondingprivate addresses saved in the NAPT record. The source IP address andport number, which belong to the client, are not altered. The IP packetis then forwarded to the server IS using the internal network interfacein step 418. In addition, the timer associated to the corresponding NAPTrecord is reset and then starts ticking.

After receiving the client-server connection request, the server ISduplicates a regular socket from the listening socket to handle thisincoming connection, with the server's private IP address and thelistening port as the socket's source address and the client's public IPaddress and port number as the socket's destination address. The serverIS can then directly answer the client.

Consequently, every IP packet sent from the server IS to the client goesback to the internal network interface of the GSA gateways in step 420b. It is understood that the IP packets may flow through other GSAgateways that act as the inside server to outside clients in step 420 a.Similarly, whenever receiving an IP packet from the internal networkinterface, the GSA gateway first checks if the source port number ofthis IP packet belongs to the NAPT port range. If so, the GSA gatewaythen checks if it appears in some NAPT record in the look-up table. Ifit does, the source IP address and port number of this IP packet, whichare private, are replaced by the corresponding public information savedin the NAPT record. The destination IP address and port number, whichbelong to the client, are not altered. The IP packet is then forwardedto the Internet using the external network interface of the primary GSAgateway in step 422 b or other GSA gateway in step 422 a.

The present invention provides a protocol for generalized client servercomputing that can support massive server-type computing acrossfirewalls based on conventional client-type techniques. The inventiveserver-type computing model is more network-friendly because it enablesusers to receive information without periodically polling a server onthe network. As a result, the amount of uplink traffic can be reducedsignificantly. Further, the URL-based scheme described above canmaximize diversity of server-type applications, increase theinteroperability between client programs and server programs developedby different vendors, and render it easier to introduce new networkingapplications. Also, the efficient use of public IPv4 addresses issignificant for relatively large service providers, since at presentthere is no class A IPv4 address block available. With the presentinvention, a service provider can set up a class A private network andsupport a relatively large number, e.g., millions, of connections acrossfirewalls simultaneously by use of only a few hundred to severalthousand public IPv4 addresses.

One skilled in the art will appreciate further features and advantagesof the invention based on the above-described embodiments. Accordingly,the invention is not to be limited by what has been particularly shownand described, except as indicated by the appended claims. Allpublications and references cited herein are expressly incorporatedherein by reference in their entirety.

1. A method of servicing a service request from a client, comprising:receiving the service request by a server from the client, the servicerequest including an installing module of a server program stored at theclient and a parameter indicating how long the server program cancontinue running after a last active connection associated with theserver program between the client and server is closed; installing theserver program on the server with the installing module in response tothe service request; selecting a port for the server program; andcommanding the server program to listen to the port.
 2. The methodaccording to claim 1, further including identifying the server with aURL.
 3. The method according to claim 1, further including providing theserver as a portable IP-based networking device.
 4. The method accordingto claim 1, further including listening on a standard TCP port for theservice request.
 5. The method according to claim 1, further includingreceiving a service request message having a command portion and ageneralized server application URL.
 6. The method according to claim 5,further including receiving a service request message having a PUTcommand in the command portion for launching a program on the server. 7.The method according to claim 5, further including receiving a servicerequest message having a PUT command in the command portion forinstalling a new program on the server and then launching the newprogram.
 8. The method according to claim 7, further including receivinga service request message having optional content.
 9. The methodaccording to claim 1, further including receiving a service requestmessage having a generalized server application URL.
 10. The methodaccording to claim 9, further including receiving a service requesthaving the generalized server application URL with a protocol name. 11.The method according to claim 9, further including receiving a servicerequest having the generalized server application URL with a server hostname.
 12. The method according to claim 9, further including receiving aservice request having the generalized server application URL with aport number.
 13. The method according to claim 9, further includingreceiving a service request having the generalized server applicationURL with a server program filename.
 14. The method according to claim10, further including encrypting at least a portion of the servicerequest.
 15. The method according to claim 1, further including sendinga message in response to the service request.
 16. The method accordingto claim 15, wherein the response message includes a port number for theserver to be used by the installed server program.